1. Field of the Invention
The present invention relates to the field of telecommunications network management systems. More specifically, the present invention relates to modeling and emulating devices in telecommunications networks for software systems.
2. Background
In the telecom industry, complex and specialized software and hardware systems are a given. Because each system is specialized, information used by one system is not easily manipulated for use in another. As a result, software designers are constantly asked to provide solutions, via software, that can integrate different systems in a consistent and easy-to-use manner.
Designing and building software that is consistently easy to use and can integrate and manipulate information from other systems is often extremely difficult. Device modeling gives to the software systems designer a method for representing behaviors of very complex devices in a model that is simple to use and understand. The model will remain the same even if the device changes; thus, the software designer is free to concentrate on the functional capability of a device.
Where a model is a simplified description of a system, a device model describes a particular element of the system. In a complex telecommunications network management system, devices might be central offices switches, PBXs, telephones, or the interfaces to applications such as work order systems, inventory systems, billings systems and so on. To build a device model, the device must first be identified: the scope of its function--"what it does", and the constraints under which it operates--"how it does". For example, to build a simplified device model of a telephone, the telephone's functions will first be identified, i.e.
1) A telephone transmits electronically encoded sounds between two locations. PA1 2) A telephone allows a user to turn on or off pre-programmed functions (features). Then, the telephone's constraints are identified, i.e. PA1 1) Activating the telephone handset sends a signal that conversation may begin. PA1 2) Dialing numbers on the keypad identifies the other person in the conversation. PA1 3) The handset at the dialed end alerts the person there that someone wishes to talk. PA1 4) When the dialed handset is activated conversation between parties can take place. PA1 5) Conversation is ended when either party deactivates his or her handset. PA1 6) To manage pre-programmed functions, the user activates the handset and presses a specific button or dials specific numbers to turn those functions on or off; then the user deactivates the handset. PA1 People talk to each other on the telephone through handsets. One person has to call the other person. The called handset must be used to answer the call. The caller must know the dialing number of the person being called. Conversation can only take place if both people use their respective handsets during the call. Either party can end the call. Telephone pre-programmed functions are controlled with buttons or special numbers.
The model is then constructed from the functions and the constraints, i.e.
In other words, the device model defines in basic terms what a device is for, how to use it, and how it works. A crucial point about device modeling is that the model can ignore many aspects of a device and still be highly valuable. In the telephone example, the concentration was on the functional aspects, and the physical descriptions such as type and color are omitted. With device modeling, the designer concentrates on what each device does, creating a functional software core that is generic and highly adaptable in integrating with other devices or components of the system. In short, device modeling separates the things that change from the things that are universal.
Device emulation is used to mimic the behavior of a modeled device and its features. Where the device model is used in the context of device emulation, the device model is invoked as part of the application. Therefore, the capability of an application can be expanded by simply providing a new device model for any given device type. Of course, different applications are free to use the emulation of a device type for different purposes. Essentially, device emulation provides the "how" to device modeling's "what". Device emulation allows new features to be introduced in the system in a standard way, thus avoiding code changes, which in turn leads a more reliable product, and shorter development cycle.
Device emulation enables system developers to focus more on the system's functional objectives than on the peculiarities of the device or network elements being managed. All information exchanges between the network management software and the network elements take the form: 1) what needs to be done--the action, and, 2) what to do it with--the data. As an intermediary between components, the device emulation adds interpretation or knowledge (the how) to the action-plus-data (the what). When a user makes a change to a device, the network management software interprets what that change means using device emulation and then makes that change directly on the device. The device's response is in turn interpreted so the management software can understand it.
Device modeling and emulation have been used in prior art products, such as the CENPAC network management software, Version 4.0, produced by American Telecorp of Redwood Shores, Calif., the assignee of the present invention. Under CENPAC, the device models are stored in a database using mass storage. As the number and varieties of devices, and complexity of telecom systems continue to increase, the traditional approach of storing and accessing device models in databases on mass storage is found to be increasingly limiting in performance as well as flexibility of the systems. Furthermore, as the device model becomes more complex, the characteristics/behaviors of a device that is modeled become highly interdependent with a large variability as to how the device model might be accessed so as to cause a particular device's characteristic to manifest itself. Typically, a manifestation of a characteristic is arrived at via a series of evaluations within the device model which may cause the access path in the device model to branch in a non-obvious manner. Thus, it becomes impractical to implement access and storage methods using the normal input/output (I/O) bound database and mass storage oriented technologies. Also the characteristics of a device can vary so greatly that it becomes impossible to predetermine the optimal database/storage schema ahead of time.
Therefore, it is desirable to bring forward a technology that is optimal for dealing with the needed flexibility when storing data and the needed access performance. The objects of the invention are to create a device model which was small enough so that it could be easily loaded as part of the execution environment of a program, and the model would allow very fast access capability and a great degree of flexibility as to how the behavior of the device might be defined. As will be disclosed, the present invention provides a method and apparatus for modeling and emulating devices in a manner that advantageously achieves the above described desirable results.